This PR introduces audit logging for critical operations in the Tables app, addressing issue #956. The goal is to enhance compliance measures by logging critical operations into a dedicated log file.

Changes

• Introduced AuditLogServiceInterface, which outlines the contract for audit logging within the application. The DefaultAuditLogService is the default implementation that dispatches CriticalActionPerformedEvent to interact with the AuditLog App. This service is auto-resolved by registering it in the Dependency Injection Container Application.php. This design allows for future extensibility, such as integrating different logging methods or services for AuditLog.

• Developed event dispatchers for corresponding events to trigger audit logs (TableDeletedEvent => WhenRowDeletedAuditLogListener, ViewDeletedEvent => WhenViewDeletedAuditLogListener, etc.). This is a standard event-driven approach that decouples auxiliary logic (logging, mail sending, etc.) from the core business logic, effectively handling side effects. Most of these operations can be executed asynchronously via a queue. Each Listener is encapsulated in its own class adhering to the Single Responsibility Principle. The AuditLogServiceInterface is injected into each listener to further promote decoupling.

Testing

Unit tests have been added for the new service and listeners. These tests can be run by executing into the server container and running composer test.

Potential Improvements

• Implementing a separate background queue worker for all listeners could offload non-business logic from the main service logic, improving performance, especially when dealing with external API calls or IO intensive operations.

• Applying Database Transactions: The TableService interacts with multiple tables simultaneously (Table, View, Row, Column). Implementing DB transactions and error handling mechanisms can ensure the integrity and reliability of operations.

Please review and provide your feedback, thank you @juliushaertl!